Fix certificate insertion #1074
Conversation
Keksoj
force-pushed
the
fix-certificate-insert
branch
2 times, most recently
from
e9a137e to
fa5480d
Compare
|
This looks like something that should be fixed in the control plane, not in sozu |
refactor: - simplify overriding of certificate names and expiration - remove trait ResolveCertificate - rename MutexWrappedCertificateResolver to MutexCertificateResolver - rearrange error types, remove useless functions - change signature of get_cn_and_san_attributes fixes: - fix concurrent certificate insert in CertificateResolver - ensure proper removal of certificate in CertificateResolver - fix removal of certificate with identical fingerprint Co-Authored-By: Eloi DEMOLIS <[email protected]>
Keksoj
force-pushed
the
fix-certificate-insert
branch
from
fa5480d to
6aa45b9
Compare
|
Maybe the comment wasn't clear enough. If Sozu has a certificate A for domain name N, and we add a new certificate B also valid for N and A is deemed "weaker" than B (all its domains are covered by B and expire before B) then A is removed in favor of B. Which I think is the intended behavior of Sozu regardless of our control plane. However, in this situation, the bug was that the fingerprint of A remained as the value for N in the Or do you suggest that add certificate should never try to replace a certificate? |
In production, Sōzu would fail when handling the AddCertificate command, in case a certificate with a concurrent domain name was present. The candidate certificate did not overwrite the outdated certificate in the TrieNode structure that maps domain names to certificate fingerprints.
This PR operates an vast rewrite of the CertificateResolver, its types and methods, and fixes the issue. On top of that, a rare and highly unlikely bug have been prevented, in case one domain name has two valid certificates bound to it.
todo: